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1 FUNCTIONAL ATTRIBUTES 


The functional attributes listed in this section define the 
major capabilities of the V500 Maintenance Subsystem. 


The following terms will be used to indicate the major 
components of the Maintenance Subsystem throughout this 
document: 


MATNTEWANCE SUBSYSTEM All of the components of the 
Maintenance Subsystem, including 
those listed below. 


MAINDENANCE PROCESSOR The component of the Maintenance 

(MP) Subsystem which performs high level 
control functions and provides the 
operator interface. The MP for the 
V500 Maintenance Subsystem is 
initially the B25 workstation. The 
MP will migrate to the Advanced 
Workstation (AWS) when it becomes 
available. 


SYSTEM MAINTENANCE The component of the Maintenance 
CONTROLLER Subsystem which provides a real 
(SMC) time interface between the MP and 


processor modules in the same cabinet 
as the SMC. The SMC for the V500 
Maintenance Subsystem is 801 86 
microprocessor based and resides in 
the processor backplane. 


ENVIRONMENT CONTROL Components of the Maintenance 
MODULE Subsystem which monitor and control 
(ECM) system power and cooling. Two types 


of CM are required, master and 
slave. The master module handles 
communication with the Maintenance 
Processor; each Slave module controls 
a@ specific power subsystem (e.g. one 
power cabinet). 
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1 FUNCTIONAL ATPRIBUTES (Continued) 
MAINTENANCE DISK(S) Disk file unit(s) connected to the MP 


and used for storing all program and 
data files used by the Maintenance 
Subsystem. The primary disk unit for 
the V500 Maintenance Subsystem is the 
Winchester disk peripheral of the B25 
or AWS. A minidisk unit is also 
provided, due to limited capacity of 
the Winchester disk, and as an 
initial boot and update path. 


Note that the terms Maintenance Subsystem, and Maintenance 
Processor are not interchangeable. 
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1.1 OPERATOR INTERFACE 


this category includes those functions that are required by 
system users (operators, software developers, etc), but not 
those that are required exclusively for field maintenance or 
hardware debug. 


iy Operator Display Terminal (ODT). This is the primary 
means by which the Operating System (MCP) accepts 
keyboard input, and displays output messages. The V500 
does not have a dedicated maintenance console; the 
Maintenance Processor performs a dual role as both the 
maintenance console and the ODT. These functions are 
performed concurrently. 


The Maintenance Subsystem may also be configured with two 
MPs to meet system fault tolerance, or user, 
requirements. In this configuration only one MP acts as 
the Maintenance Subsystem controller (and also performs 
ODT functions), the other performs OD? functions only. If 
the controlling MP fails, the other MP will recognize the 
failure and take over it's functions. 


When the system is configured with two MPs, one may be 
dedicated to maintenance functions only, while the other 
continues to function as the system ODT, thus 
facilitating on-line system maintenance. 


b. Operator Console. The Maintenance Subsystem supports the 
following operator control functions: 


i. System Initialization 
(See 1.1.1 for a more detailed breakdown of this 
function.) 


ii. System Configuration Control 
iii. Date and Time Clock. This clock maintains the 
current Date and Time, passing it to the MCP during 
a HALT/LOAD. After the system is halt/loaded, the 
MCP maintains it's own independent date and time 
clock. 
iv. System Status Display 
Simplicity of operation will be enhanced by the use of 
menu(s) for common operator control functions. 
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bel OPHRATOR INTERFACE (Continued) 
Ce Programmer Console. The Maintenance Subsystem supports 


the following functions for software debug: 


i. Memory Access (Read, Write, and Clear system 
memory.) 


ii. Program State Access 
(OMEGA structure access will be supported). 


iii. Single Instruct 
iv. System Status Display 
v.- Stop on OP, on Instruction Address, or on _ other 
conditions considered appropriate for the programmer 


environment. 


As with the Operator Console functions, menus are used to 
enhance usability wherever this is appropriate. 
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1.1.1 SYSTEM INITIALIZATION AND CONFIGURATION 
The V500 Maintenance Subsystem provides the means by which the 
operator brings up the system from power-off to the MCP 
running state. The procedures involved are quick and simple to 
execute. Standard initialization command sequences are 
pre-programmed to allow "Single keystroke" HALT/LOAD, etc., 
and menu operation is emphasized. 
The following functions are provided: 
1. Control Store LOAD. 
2. Control Store VERIFY. 
3. set Options: 
Be MCP unit 
b. ALT unit 
Ce Memory size 
d. Memory configuration 
#4. Load OD? DLP firmware (Uniline or equivalent). 
#5. Load Disk Controller firmware. 
6. Load Bootstrap for MCP loading. 
7- load Bootstrap for ALT loading. 
8. Set MP DATE and TIME. 
#9. Memory dump to tape (via Control state program). 
#10. Add/Subtract processors from the active list. 
11. Single Keystroke System boot. 
Functions or features marked with a pound sign (#) will not be 


included in the first release. Later availability is not yet 
scheduled. 
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1.2 MAINTENANCE INTERFACE 


This category includes those functions that are required for 
hardware maintenance or debug only. ‘Two distinct levels of 
maintenance are supported. The first level assumes minimal 
system knowledge, and is geared to fault isolation to the FRU 
level, with as little operator interaction as possible. This 
interface is largely menu driven. The second level (which 
includes debug) is intended for more highly trained personnel 
seeking to pinpoint functional failures, and keyword commands 
are utilized for control in addition to menus. 


1.2.1 FIELD MAINTENANCE - PRIMARY LEVEL 


Primary Level Field Maintenance is concerned with physical 
level fault isolation, and reguires a minimal operator skill 
level. Features provided for this level of maintenance are 
designed to facilitate rapid isolation of a fault to a Field 
Replaceable Unit (FRU). The FRU is normally a circuit board, 
mechanical component, or power module. Functional analysis of 
the problem is secondary to rapid isolation and replacement of 
a failing FRU. 


Interfaces are provided within the Maintenance Subsystem, and 
between the Maintenance Subsystem and the Host System, which 
permit the implementation of diagnostics and other tests 
capable of isolating hardware problems to the FRU level with 
minimum operator interaction. 


A software driven diagnostic flow is incorporated which 
permits primary fault isolation to be accomplished 
automatically (without operator interaction) when an error is 
detected. 


Initial problem diagnosis in the field will most often be 
performed via a REMOTE link. For this reason, priority is 
given in the Maintenance Subsystem design to facilitate this 
process (See Sections 1.4 and 2.4). The automatic diagnostic 
process mentioned above will reduce the number of transactions 
required, via the REMOTE link, by performing primary fault 
diagnosis before the remote connection is made. 
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1.2.1 FIELD MAINTENANCE — PRIMARY LEVEL (Continued) 
Specific capabilities include: 
ae Error detection logic within each system module (eg. 


circuit card), which outputs a signal to the Maintenance 
Subsystem wnen an error occurs. 


De Module self-tests are provided for the processor, and 
these are executed on power-up, as part of the diagnostic 
flow, and in response to a specific operator request. 


Ceo Central system diagnostic tests are resident on _ the 
maintenance disk and are automatically invoked on the 
occurrence of an irrecoverable error. 

Hd. A SYSTEM THES? flow is provided, and is resident on the 

Maintenance Disk. Hxecution is initiated by a single 
console command. The flow verifies error free operation 
of all components required to Halt/Load the system 
(including the fact that a copy of the MCP is resident on 
the system disk), using a "bottom-up" diagnostic 
approach, selectively executing diagnostic tests. It is 
utilized when system status is uncertain. 
Error messages from test routines include identification 
of the suspect physical modules, or guidance as to the 
means by which an accurate diagnosis may be made (e.g. 
what other tests should be executed). 

e. TEST PUNCTIONS 
Test Chain(s) 
fest RAM(s) 

Test Memory 

Path Tests 

Module Function (Microcoded) Tests 
Control State IO and Processor Tests 


it M@P-driven On-line I0 Tests 
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1.2.2 FIELD MAINTENANCE - SECONDARY LEVEL, AND DEBUG 


Secondary Level Field Maintenance (second level support), and 
System Debug are concerned with functional level fault 
diagnosis, and assume a higher operator skill level than 
required for Primary Level Maintenance. 


Tools provided for use at this level assume the user has a 
knowledge of the system architecture, and wants to isolate a 
problem beyond the FRU level. 


Specific functions provided include: 
Ae PRIMITIVE CONTROL FUNCTIONS. 
CLEAR : Clear all machine state 
Clear selected modules 
Clear a selected chain 
Clear the SMC 
CLOCK : Clock all modules 
Clock a selected chain 
Clock selected modules 
Clock burst (chain or modules) 
SluT AND DISPLAY STATE : 
All chain and RAM elements individually 
Set pattern in any chain 
b. MEMORY CONTROL FUNCTIONS 
Clear all, or a part of memory to zero 


Read and Write memory 


set all, or a part of memory to a pattern 
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1.2.2 FILD MAINTENANCE —- SECONDARY LEVEL, AND DEBUG (Continued) 


Ce SYSTEM CONTROL FUNCTIONS 


Load and verify module control stores 
Single Instruct 

Single Clock 

TERM/HALT 

RUN/<SPCFY> 

INIT/PA 


Static and Dynamic Record 


d. STOP ON EVENT. Stop events will be specified as the V500 
architecture becomes more clearly defined. The operator 
interface is via a menu similar to the Maintenance Panel 


on the B4900. 


The stop logic compare and enable functions are 
implemented in the individual processor modules, via 
dedicated maintenance chains. Two interrupt lines to the 
SMC are provided from each processor. An option is 


available to permit modules to stop themselves 


when a 


stop condition occurs. If this option is not enabled, 
module and processor halts, in response to the occurrence 
of a stop event, will be under the control of the SMC. 


1.2.5 MAINTENANCE PLAN 


The architecture of the Maintenance Subsystem takes into 
consideration the need for a complete maintenance capability 


in all areas of the system hardware. 


Internal errors detected within each processor card 


trigger 


the Maintenance Subsystem to perform a problem analysis and 
record procedure. If applicable, a recovery procedure is 


initiated. The error is logged, and the faulty 
indicated in the error report. 


ecard is 
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1.2.3 MAINTENANCE PLAN (Continued) 


The result of the error analysis will be displayed on _ the 
maintenance console in a form indicating the nature of the 
error, and the name and location of the failing module or 
ecard. A failure history file is also maintained on the 
maintenance disk. 


Performance-driven maintenance features include auto-diagnosis 
of hardware problems and automatic dial-up of the Remote 
Support Center. All maintenance functions and diagnostic 
capabilities are available remotely. Auto-answer is provided 
as an optional feature if it is required to support corporate 
remote support strategy. 


Specific plans for the major subsystems are described in the 
following paragraphs. 


Be MAINFRAME POWER and COOLING 


The Maintenance Subsystem interfaces to the power and 
cooling modules through intelligent, self testing, 
Environmental Control Modules. These modules monitor and 
control power and cooling, and report their status on 
request, or automatically if an error occurs. In the case 
of a power module failure, the report from the ECM 
indicates the failing module. 


The ECMs are designed to handle critical power problems 
independently of the Maintenance Subsystem if necessary 
to protect the system from damage. 


If the ECM module itself fails, it is designed to fall 
into a "hard wired" control mode, in which power is 
locked into nominal and cannot be varied. If control is 
still not possible, power is automatically taken down. A 
clear signal is driven to the processor when a power-down 
is imminent. 


The repair philosophy for the power and cooling 
subsystems is to replace the failing module. 


b. MAINTENANCE SUBSYSTEM 
“he components of the Maintenance Subsystem utilize 
resident SHELF TESTs as the primary means of fault 
isolation. The Self Tests execute automatically on Power 
Up and whenever requested by the operator. 
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1.2.3 MAINTENANCE PLAN (Continued) 
They include a basic test of the maintenance disk(s). 


The SMC incorporates a LED display panel (visible from 
the card frontplane) which provides an indication of its 
status, including the results of any self test failure. 
The SMC Self Test is executed as a low priority task 
during normal operation. 


All OD’ displayed error messages will contain a_ specific 
indication of which hardware component (FRU) is suspect. 


More extensive, non-resident, tests for each of the 
Maintenance Subsystem components are stored on the 
maintenance disk, and may be executed under operator 
direction. Default execution of these tests may be 
initiated by the Maintenance Subsystem itself in the 
event that an internal error is detected and resident 
self tests complete without error. 


om PROCESSOR (including MEMORY and I0Ts) 


The designs of the central system modules include 
extensive error detection logic. This logic permits many 
problems to be diagnosed by the Maintenance Subsystem to 
the card or module level, based only on the location and 
type of error reported. When a processor error is 
detected, an extended processor result descriptor is 
written into system memory to alert the MCP to the 
occurrence of the problem, and if applicable, a recovery 
is attempted. It is anticipated that recovery will be 
possible for at least 60% of all transient processor 
errors (excluding memory storage boards, where the 
recovery rate is expected to be close to 100%). (At least 
80% of all errors are expected to be transients). 


The designs of the central system modules further 
incorporate extensive provisions for testability. These 
provisions include implementation of shift register paths 
for static state access and testing, as well as 
accessibility of control signals and data as required for 
module self-testing. 
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1.2.3 MAINTENANCE PLAN (Continued) 


If a recovery is not possible or fails, diagnostic tests 
are automatically invoked by the Maintenance Subsystem. 
These tests, all resident on the maintenance disk, 
include: 


i. PATH tests. These tests use shift register paths to 
set up and observe state. They provide excellent 
coverage for stuck-at faults. 


ii. MODULE FUNCTION tests. These tests consist primarily 
of microcode used to perform self-testing at full 
speed to aid in diagnosis of intermittent and 
timing-sensitive faults. Modules which have no 
control store, are self-tested by means of microcode 
in other modules, or in some cases by cycling under 
conditions initiated by the maintenance processor. 


1ii. CONTROL STATE CONFIDENCE tests. These tests execute 
the medium systems instruction set to verify correct 
operation of the entire processor, including the 
functional microcode. 


The tests are executed in the order that best suits the 
type of problem reported. 


Clock and Voltage margins may be applied under the direct 
control of the Maintenance Processor to aid in the 
isolation of intermittent problems. 


d. I/O COMPONENTS HOUSED IN THE MAINFRAME 


fo avoid system downtime for I/O module maintenance, all 
testing is planned to be done in the on-line environment, 
without interfering with operational components. 


A few DLPs incorporate a Self Test capability that will 
permit the isolation of most failures in these modules to 
the FRU without external stimulation. These tests are 
executed automatically at power-up, whenever the module 
is cleared, or when the system sends the Self Test I0 
descriptor to the DLP. It is the responsibility of the 
Operating System to confirm a good Self Test result, 
before allowing a module to be added to the system 
configuration. 
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1.2.3 MAINTENANCE PLAN (Continued) 


Testbus diagnostics are available for DLPs that do not 
have Self ‘est capability. These diagnostics reside on 
system disk, and are issued via the SMC in the on-line 
environment, under control of the on-line test bus driver 
program. Off-line capability also exists. 


# In addition to Self Test, and Test Bus diagnostics, MP 
driven tests are available which run in parallel with 
normal system I/0 operations. Failing devices are "saved" 
(deleted from the MCP configuration), and are then tested 
by the MP in a manner which simulates normal operation 
(i.e. the MP initiates 1/0 operations via main memory, 
using the same I/O control block mechanism as the MCP). 


Normal State tests (PTD driven) are also available to be 
executed in the system mix. 


Control state PTD tests are also available for critical 
path devices. 


Ce I/O COMPONENTS HOUSED OUTSIDE OF THE MAINFRAME 


Peripheral devices (including controllers) continue to 
include more self Test capability. This applies 
particularly to OM devices. As a result, off-line 
testing of these devices is the preferred form of fault 
diagnosis. Peripheral self test results should be, but 


presently are not, accessible by the maintenance 
processor for remote support. A means for the 
maintenance processor to acquire the results of 


peripheral self tests is needed. 

Where such self test capability is not available, Normal 
State PTD driven tests are available. In Some cases 
Normal State Confidence Tests are also available. 


# MP driven tests that execute in parallel with, but 
independently of, the MCP exist for critical peripherals. 
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1.3 PAULT HANDLING AND RECOVERY 


The MP plays a role in the processor error recovery process, 
and handles extended error logging and analysis functions via 
its own Maintenance Log (MPLOG). This log supplements the MCP 
MLOG, and improves system availability through real time error 
analysis and fault prediction. 


The MPLOG is restricted to "hardware" errors. Software errors 
are still handled exclusively by the operating system, which 
also stores all MPLOG data. 


# Hardware fault isolation in a multiple processor environment 
requires the ability to run diagnostics on a suspect module, 
without interrupting the operating system. 


The MP displays "warning" or system status messages on the OD? 
when the occurrence of recoverable errors reaches a 
pre-defined frequency threshold for specific problem types. 


# The MP may initiate a call to a remote support center for 
hardware support. 


An automatic on-line (MP driven) diagnostic process is 
provided, which permits preliminary diagnosis of system 
problems to be made without operator intervention. 


Detection of an error by the processor causes an Interrupt to 
the SMC, which initiates a SNAP. The MP stores the SNAP 
picture in system memory, and on its own disk. The MCP keeps 
the SNAP picture for all errors. 


The SMC or the MP (depending on the complexity of the 
analysis) determines from the SNAP information if an 
instruction retry should be attempted. The decision is based 
on the type and location of the error, the state of the RETRY 
flag in the Execute Module, and the recent error history of 
the processor, among other factors. 


If a retry cannot be attempted, an error message is displayed 
on the ODT and the processor is not restarted. # In a multiple 
processor configuration, a Processor RD is written into memory 
indicating the nature of the failure. This RD is interpreted 
by the MCP via one of the surviving processors, and further 
action (e.g. job termination, and processor initialization), 
is handled at the operating system level. 
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tae FAULT HANDLING AND RECOVERY (Continued) 


If a retry can be attempted, the MP will initialize the 
processor to the appropriate starting point, place it in 
single instruct mode, and cause the failing OP to be 
re-executed. If the OP executes without error, the MP logs the 
successful recovery, and places the processor in normal run 
mode. If the OP fails again immediately, two further retries 
are attempted. If a successful execution cannot be made, the 
error is assumed to be hard, and it is handled as if no retry 
were possible. 


1.4 REMOTE INTERFACE 


The MP has a Remote Interface and appropriate software to 
permit the system to be accessed from a remote center, both in 
active and passive modes. 


The physical connection is a single data comm link for both 
hardware and software support. 


A security mechanism is designed into the remote interface. 
This consists of a keylock arrangement and software security. 
Remote transmissions are also encoded. 


Remote capabilities include bidirectional file transfer, the 
ability to switch the line back and forth between data and 
voice modes while maintaining the logical and physical 
connection, and message exchange between the RSC workstation 
and the target system ODT/maintenance console or local 
terminal. 


Data communication transmission mode and line speed will be 
configurable from the maintenance console via a "Remote 
Configuration" menu. 


The AWS incorporates a built-in modem, with auto-call. 
Auto-answer may be available for performance driven 
maintenance. Local regulations may prohibit the use of a 
built-in modem at some International sites; in this situation, 
the remote connection will be via a RS232 port, and auto-call 
and answer features will be dependent on local modem 
capabilities. 
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1.4 REMOTE INTERFACE (Continued) 


The Maintenance Processor is powered independently of the rest 
of the mainframe, and is able to remain powered-on even when 
the mainframe is powered-off. The system may be powered-on via 
the remote link in this situation. This capability may be 
extended to peripheral units that are able to interface to the 
ECM net (i.e. have their own ECM slave equivalent). local 
switches in each cabinet will remote power-on of any unit. 


The remote interface will use a subset of the Burroughs Dialog 
Block protocol as described in the following specifications: 


# 3398 2075 Dialog Block Protocol for Remote Support 
3398 2067 Message Block Protocol for Remote Support 
3398 2059 EHight-bit Data Communications Protocol 

for Remote Support 


This protocol is currently being used on the AY system, and is 
specified for the A3 and Alb. 


A terminal emulation protocol will also be available 
(poll/select) to maintain compatibility with the 
B2900/B3900/B4900 remote interface, and allows communication 
with existing Medium System Support Centers. 


Additional high level protocols (such as X.25), necessary for 
future communications particularly in International regions, 
will be defined and implemented as required to support 
Corporate maintenance goals. 


TD HNVIRONMEN?TAL MONITORING AND CONTROL 


The Maintenance Subsystem monitors and controls key 
environmental factors as follows: 


MONITORS AND REPORTS, 
i. POWER VOLTAGES (AC/DC, STEADY STATE, and TRANSIENTS) 
ii. AIR TEMPERATURE (at various locations within the 
cabinet) 
CONTROLS, 
i. DC VOLTAGE LEVELS (ON/OFF, and CONTINUOUSLY VARIABLE 
MARGIN ADJUSTMENT ) 
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1.6 RELIABILITY 


The Maintenance Subsystem, as one of the most crucial system 
components, is designed to be extremely reliable. The 
subsystem may be configured to be fault tolerant, and in this 
configuration a minimum availability of 99.995% is guaranteed. 
This availablity is achieved with a MIBF of 20,000 hours, and 
a WYGR of 1.0 hour or less, where a failure is defined as loss 
of all Maintenance Subsystem capability. 


A failure in the Maintenance Subsystem will not cause a system 
crash (for the most probable failure modes), but may 
precipitate a controlled system interrupt. 


1.7 # MULSI-PROCESSOR INDERFACE 


The Maintenance Subsystem is configurable to support from one 
to four processors. This implies that a capability to perform 
maintenance functions on a Single processor, while 
concurrently performing ODT, and monitor and control functions 
for up to three others. 
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2 DESIGN ATTRIBUTES 
ax GENERAL DESCRIPTION 


The V500 Maintenance Subsystem utilizes six distinct types of 
hardware modules, some of which may be duplicated depending on 
the system configuration (number of processors) or fault 
tolerance requirements. 


The six modules are: 


CONTROL MOD 
(SLAVE) 


MODULE | NUMBER IN MINIMUM | NUMBER IN MAXIMUM 
| CONFIGURATION | CONFIGURATION 
meses es esses sssas* sets rssss esses sess ssa sess ss seeesssss 
i | 
| | 
1. MAINTENANCE | 1 2 
PROCESSOR ! 
| | 
| | 
2. SYSTEM | 1 | a 
MAINTENANCE | ! 
CONTROLLER | 
} 1 
| | 
3, 20MB 5 1/4"*x | 1 ! 2 
WINCHESTER | 
DISK DRIVE * | | 
| 
| | 
4. SINGLE 4 ! D, 
640KB 5 1/4" | | 
MINI-DISK * 
| | 
5. ENVIRONMENT 1 2 
CONTROL MoD | 
(MASTER) | 
t t 
6. ENVIRONMENT | a | TBD 
} 
| 


* DISK CAPACITY IS UNFORMATIED 
** REQUIRES 2 10MB DRIVES ON THE B25 


A B25 workstation is used as the Maintenance Processor (MP), 
and therefore keyboard and display functions are included. The 
B25 will be superceded by the AWS (Advanced Work Station). 
The AWS will then replace the B25 as the Maintenance 
Processor. 
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261 GENERAL DESCRIPTION (Continued) 


The MP provides overall control of the Maintenance Subsystem, 
communicating with the other subsystem components through 
external interfaces, as follows: 


1. A high speed serial network interface to the SMC. This is 
the RS422 cluster port on both the B25 and AWS. 


is The AWS and B25 have a parallel port to the Winchester 
disk, which is also utilized for the mini-disk. 


or An RS232 interface provides the Remote Port. The AWS may 
have an optional built-in modem, otherwise an external 
modem will be required. 


4. Another RS232 interface is available. # It may be used to 
provide a redundant path for ODT functions through the 
I/O Subsystem, or as a communication path between two MPs 
in a dual configuration. 


5. A Centronics Printer interface. Utilization is TBD. 


The System Maintenance Controller (SMC) is a microprocessor 
(80186) based module, which provides high speed interface to 
one or two processors (if they are housed in the same 
cabinet), the I0Ps, DIMs, and Memory Storage Boards. The SMC 
is an interrupt driven real time processor. A _ parallel 
interface is provided to the I/0 bus to allow for high speed 
memory access, and to permit the Maintenance Subsystem to be 
accessed as an I/O Channel by the operating system. 


The TESTBUS interface required for DLP maintenance is also 
included in the SMC. It may be driven by the system or the MP. 


One MP can handle up to four processors (maximum V500 
configuration), but a second MP may be installed as a fault 
tolerance option. In this case, the second MP monitors’ the 
state of the first while the first continues to perform all 
normal MP functions. If the first MP dies, this is detected by 
the second MP which takes over control. 


Ghere are two RS5422 busses on a system configured with two 
MPs. Hach MP is connected to a separate bus, and the SMCs and 
ECiMls are connected to both (dual ported). This provides a 
level of protection against the failure of any one bus taking 
down the system. 
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261 GENERAL DESCRIPTION (Continued) 


The Winchester disk drive contains the program and data files 
to perform all the normal system initialization and 
troubleshooting functions assigned to the Maintenance 
Subsystem (see Section 1 of this document). ‘This permits 
rapld system initialization, and automatic execution of 
diagnostics under programmatic control when a failure is 
detected. @he MP also maintains an error log (MPLOG) on the 
Winchester, and provides for temporary storage of up to two 
SNAP pictures per system processor. 


The mini-disk serves as a backup to the Winchester in the 
event that no path is available to system tape or disk (the 
normal backup media). It also provides an alternate means of 
loading and running UIO diagnostics. 


The Environment Control Modules are intelligent units which 
provide the control and monitor interface between the MP and 
the Power and Cooling Subsystem. They also provide hardwired 
control in the event of a MP failure or a catastophic 
environmental problem, to ensure the protection of the 
mainframe logic. A single Master ECM in each processor cabinet 
communicates with as many Slave ECMs as are required to 
control system, and potentially peripheral, power. 


202 MAINTENANCE SUBSYSTEM INTERFACING 


Although the MP maintains overall control of the Maintenance 
Subsystem, the "intelligence" is shared with the SMC. This 
permits the SMC to handle some complex processor and memory 
interfacing and monitoring tasks with minimum MP involvement, 
freeing up the MP to handle the other interfaces more 
efficiently. The Maintenance Subsystem interfaces are 
therefore grouped into MP controlled and SMC controlled types. 
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2.2.1 WMP INTERFACES 
INTERFACE | MAXIMUM | GENBRAL DESCRIPTION | BANDPASS 
DEVICE | NUMBER | | (/SEC,MAX) 
1. REMOT® PORT} 1 | RS232 | 4200 BAUD Min. 
{ MODEM OUT (AWS) 1200 BAUD Min. 
| | i] 
2. MINI-~DISK { PARALLEL | BD 
i] 
{ { ] 
%. WINCHESTER ! { | PARALLEL ' @BD 
i 1 | 
{ | | 
4. BCM ! 2 
SMC ta 4 | 
MP | RS422 BUS 1.8 MBits 
i | | 
5. PRINTER { CENTRONICS 
{ 
| { 
| | | 


6. LBD RS232 (SPARE) 9600 BAUD Max. 
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2.2.2 SMC INTERFACES 
INTERFACE | MAXIMUM | GENERAL DESCRIPTION | BANDPASS 
| NUMBER | | ( /SEC) 
| 
1. MP 2 RS422 1.8 MBits 
{ | I 
2. PROCESSOR } 2 | See Section 3 | SYSTEM 
STATE ! | CLOCK 
(CHAINS) | | RATE 
| | t 
3. PROCESSOR | 2 | See Section 3 | N/A 
ERR./STOP | 
| 
1 | { 
4. PROCESSOR ! 2 | See Section 3 | N/A 
CLOCK 
CONTROL | | 
| | i] 
t { ] 
5. 1/0 BUS { | 32 BITS DATA/8 ECC | 50 MBYTES 
| | nn BITS CONTROL 
| i} { 
6. TESTBUS ! 1 ! O-WIRE BDI ' 19,.2K BITS 
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269 SYSTEM ARCHITECTURE 


Figure 2.1 illustrates the integration of the Maintenance 
Subsystem components into a large V500 system configuration. 


The configuration shown is a four processor, dual cabinet 
system with two Maintenance Processors (the maximum, fault 
tolerant configuration). 


Figure 2.1 illustrates the system architecture utilizing a B25 
as the Maintenance Processor. In this configuration, one B25 
performs the Maintenance Processor role for the whole system, 
communicating with all four processors, and associated ECMs, 
via the cluster. This B25 performs ODT functions concurrently 
with the MP functions when the system is running under MCP 
control. 


The second B25 performs only as an ODT as long as the first 
B25 continues to function as the MP. It monitors network 
activity, via the SMC, to determine if the MP is still alive. 
If the MP B25 dies, the second B25 automatically takes over 
its role, initiates the diagnostic process, and reports the 
problem to the operator. 
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FIGURE 2.1 
V500 CENGRAL SYSTEM ARCHITECTURE 
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2.4 MP ARCHITECTURE 
Figure 2.2 illustrates the configuration of the B25 
Maintenance Processor. The design is based on the 80186 
microprocessor, and includes the following features: 
Be 512KB RAM 
De nnkB ROM 
Ce fixternal Interfaces: 
2x RS2352 
ix RS422 Cluster Port 
1x Centronics Printer 
d. Integrated Self Test 
om Time of Day Clock 
f. 20MB Winchester/640KB minidisk subsystem 


ie bE" Color monitor with graphics controller 
(optional ~ TBD) (Not shown in Figure 2.2) 


--Burroughs Prior Written Consent Required For Disclosure Of This Data-- 


1995: 3503 

BURROUGHS CORPORATION FASO ae A as See ERE are ee a E: 
SYSTEMS DEVELOPMENT GROUP ! | 
PASADENA PLAN? ! 500 MAINTENANCE SUBSYSTEM 

} 

' 
COMPANY Ee re ee cee ae ee ele ee ee ee 
CONFIDENTIAL SYSTEM DESIGN SPECIFICATION Rev. A Page 29 

FIGURE 2.2 
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2.5 SMC ARCHITECTURE 


Figure 2.5 illustrates the basic architecture of the System 
Maintenance Controller. 


Be The SMC is microprocessor based, which allows for greater 
operational flexibility, and an offloading of some 
control functions from the MP. 


b. The SMC shares the interface to the IOMC with the 
IOPs/DIMs, permitting direct system memory access by the 
Maintenance Subsystem, which enhances both normal and 
diagnostic performance. 


Ce The SMC can interface to two processors (as long as they 
share a common cabinet), thus the processor status and 
clock control interfaces are expanded. 


d. The Maintenance Bus is divided into an ECL bus anda TL 
bus to handle module interface requirements. 


ee The DLP TESTBUS is driven from the SMC. 

£, The SMC contains the system clock generation logic, which 
is implemented as a logically separate function within 
the module. 


The SMC has dual RS422 ports, enabling independent 
connection to two B25s. 


ca 


-~-Burroughs Prior Written Consent Required For Disclosure Of This Data-- 


1993 5303 
BURROUGHS CORPORATION FOS eR Re Wy SO ee ee eae ne 
SYSTEMS DEVELOPMENT GROUP } 
PASADENA PLAN? V500 MAINTENANCE SUBSYSTEM 
| 
] 
COMPANY Sa a eh pa a or Se 
CONFIDANTIAL SYSTEM DESIGN SPECIFICATION Rev. A Page 31 
FIGURE 2.3 
V500 SMC MODULE BLOCK DIAGRAM 
DUAL 
CLlLusTee 
Feet TESTAUS 
be Mbe7U56 Mita, : 
RS422 | | 
UsAaRT 


SELEVER 


170 BUS RAM/EPROM 


C4K EPO 
64K S.RAaM CS50n¢) 
4K FAST RAM (uSas) 


2 MBytedcoc 
SYSTEM 


MAWTENANCE | aa 
Bus [@) @US 


PRocEssoR 
BoAaRsas 


--Burroughs Prior Written Consent Required For Disclosure Of This Data-- 


BURROUGHS CORPORATION fee eee mee eee ee eee eee + 
SYSTEMS DEVELOPMENT GROUP 
PASADENA PLANT | V500 MAINTENANCE SUBSYSTEM 
{ 
t 
COMPANY ewe eee er ee ee ee ee 
CONFIDENTIAL SYSTEM DESIGN SPECIFICATION Rev. A Page 32 
2.6 FAULT TOLERANCE 
The MP and SMC are reliable components but are not 


individually fault tolerant. Fault tolerance can be achieved 
at the subsystem level by adding redundant modules into the 
configuration as discussed in Section 2.3. 


some redundancy options are only applicable to dual cabinet 
systems, so a fully fault tolerant system includes two CPUs, 
each housed in a separate cabinet. Each CPU has its own SMC 
and MP (although only one MP is active at a time). 


The Maintenance Subsystem components with the lowest predicted 
availability are the B25 and the Winchester Disks. In the 
event of a failure of one of these components, system 
operation may continue through the use of backup components, 
although throughput may suffer. (Another B25 may be installed 
as an ODT, and Mini-Disk and/or system tape is accessible by 
the MP as Winchester disk backup). 


2. MAINTAINABILIPY 


Each of tne Maintenance Subsystem components listed in Section 
2.1 will be maintained in the field on a replacement basis 
(each component is an FRU), with the exception of the B25, 
which will be maintained on a module replacement basis. 


The B25, SMC, and ECM include integral self test capability. 
Each of these units executes a self test on power-up, system 
clear, or when initiated under operator/software control. An 
indication of the status of each unit. is available 
independently of the state of the other subsystem components. 
The SMC and ECMs use LEDs; the B25s use a combination of LEDs 
and On-Screen messages. 


The Winchester and Mini-Disks are testable with operator 
initiated diagnostics. The test results are displayed on the 
Bed screen. 


The MP/SMC interface is also tested by a MP resident 
diagnostic. In the event that the MP cannot communicate with 


the SMC or the Winchester disk, an appropriate message is 
displayed on the B25. 


ixtensive disk-resident Maintenance Subsystem diagnostics are 


available to assist in the isolation of problems not located 
by either the self-test or the resident diagnostics. 
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3 MAINTENANCE AT?RIBUTES OF V500 HARDWARE 


This section describes the hardware features of the V500 
system that are utilized by the Maintenance Subsystem to 
perform its various tasks. 


4.4 STATE ACCESS 
Shift chains provide access either directly (on the chain) or 
indirectly (can be gated onto the chain) to all state within 
the V500 processor, including the Memory Control Modules, 


Memory, DIMs, and IOTs. 


Kach card has a maximum of two chains. One may be designated 


the Maintenance Chain and if so, it is reserved for 
maintenance functions only, primarily implementation of 
Maintenance Panel compare logic. The other chains, 


collectively referred to as Data Chains, provide access to all 
remaining state. 


One SMC provides the maintenance interface to all processor 
modules within a single cabinet. Thus, in some multi-processor 
configurations one SMC interfaces to two independent 
processors. Fault tolerance may be achieved in dual cabinet 
systems, as each cabinet has its own SMC, permitting the 
system to continue operation in the event that one SMC fails 
(this capability is system software dependent). 
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ore INTERRUPT SYSTEM 


A major function of the SMC is to monitor the processor, 
memory control, and IOs for error conditions. This is done 
through an interrupt mechanism, in which each processor module 
has its own unique ERROR interrupt signal to the SMC. 


The outputs of the various error detection circuits within 
each processor card are clocked into an lrror Register, which 
includes a bit for each kind of error that can be detected 
within the card. The outputs of the register elements are 
then or'd together and driven to the SMC as the module ERROR 
Signal. The elements of the error register are contained on 
the card data chain. 


Whenever possible, the elements are grouped together on the 
chain. The ERROR signal is also used internally within each 
module to disable the module clock, thus freezing the module 
on the occurrence of an error. A bit is made available on the 
maintenance chain to allow this automatic clock stop function 
to be disabled for debug or maintenance. 


When an error interrupt signal is received by the SMC, it will 
begin an error handling process appropriate to the error type. 
This process may include bringing the remaining modules in the 
failing processor to a controlled halt, performing a SNAP, and 
attempting a recovery. 
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D3 SYSTEM MEMORY ACCESS 


The SMC interfaces to the I/0 Memory Concentrator via the 1/0 
Bus. This allows the Maintenance Subsystem to access the 
system memory at high speed in both off-line and on-line 
modes. 


In the off-line mode, this permits more thorough and _ rapid 
testing of the memory and the IOT, DIM and IOMC modules. The 
program LOAD function can be handled much more efficiently 
through this interface than through the use of the memory 
shift chains. 


In the on-line (MCP) mode, this interface permits the 
implementation of a communication path between the Operating 
system and the Maintenance Subsystem. This path is used for 
such things as writing the Processor SNAP picture into memory 
after an error has occurred (this must be done without 
stopping normal memory operation in a multi-processor system). 


The on-line interface also provides a path for the Operating 
System to access the Winchester Disk (for updates, etc.), and 
other Maintenance Subsystem components, such as the B25 (for 
ODT functions) and Remote Port. 
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3.4 CLOCK CONTROL 


The SMC controls activation of the clock within each of the 
processor modules. Control is ona card by card basis with 
each card having its own clock enable line. 


The clock may be activated in either of two modes: 
1. Normal Mode 
2. Maintenance Mode 


In Normal mode, all clocks within selected modules are 
activated or deactivated as a single group. In Maintenance 
Mode, clocks are controlled at the card or module level. 


This mechanism permits the Maintenance Subsystem to control 
the system on a clock by clock basis at the card, module, and 
system level. 


While a module is receiving clocks in Normal mode, a 
Maintenance chain may be placed in shift mode, thus permitting 
access to this chain to take place without interrupting normal 
processor operation. 


The SMC-also maintains control of the system clock frequency 


via a register in the clock. generator. Maximum deviation from 
nominal that can be accomplished is 17.B.D. 
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bree. STOP LOGIC 


Stop logic is implemented via the Maintenance Shift chains. 
There is a register on a Maintenance Chain corresponding to 
any function for which stop logic is desired. The register is 
loaded with a value which is constantly compared to the value 
of the function being monitored. If an equal condition occurs, 
and if the enable toggle is set, a STOP signal is gated to the 
SMC. 


The stop condition active levels within each module are OR'd 
together with other modules and bussed to the SMC as two STOP 
Signals, STOP-AND and STOP-OR. 


When a module STOP signal is received by the SMC, it will 
bring the processor to an orderly halt. 


-~Burroughs Prior Written Consent Required For Disclosure Of This Data-- 


1993 530% 
BURROUGHS CORPORATION fee me a ce at ea we ee + 
SYSTEMS DEVELOPMENT GROUP 
PASADENA PLANT V500 MAINTENANCE SUBSYSTEM 
if _ 
COMPANY fm Se nee eS Cle ee eee 
CONFIDENTIAL SYSTEM DESIGN SPECIFICATION Rev. A Page 38 


3.6 SMC-PROCESSOR INTERFACE 


The SMC interfaces to the processor modules via two backplane 
Maintenance Busses. One bus is implemented in ECL and 
interfaces to the XM, FETCH, MEMORY CONTROL/CACHE, and MEMORY 
STORAGE modules. The other bus is implemented in TTL, and 
interfaces to the IOT and DIM modules. The IOMC contains both 
HCL and TTL logic and is interfaced to both the TTL and ECL 
busses. 


The two busses are logically the same, although the 
implementation varies slightly due to packaging and loading 
differences. 


Functions, handled via the interface, fall into two broad 
categories: CLOCK and CLEAR control, and STATE ACCESS via 
shift chain manipulation. These functions are controlled at 
the module level, a module being a card or group of cards that 
has a distinct functional identity. 


Within a module, clock functions may be performed at the card 
or module level. Clear functions may be performed at the 
module or chain level. 


One SMC provides the maintenance interface to a _ single 
processor cabinet, which may contain one or two processors. 


The SMC Processor Interface is further defined in the SMC 
Engineering Design Specification (see "Related Documents"). 
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4 MAINTENANCE ATTRIBUTES OF SYSTEM SOFTWARE 
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The architecture of the V500 Maintenance Subsystem permits it 
to interact with the Operating System software to perform 
certain key functions. 


Many of these functions rely on the ability of the SMC to 
emulate a DTM, and thus communicate with the MCP as a regular 
I/O device. 


SYSTEM OD? 


During normal system operation (when no maintenance is being 
performed), the primary function of the Maintenance Processor 
is to act as a system ODT. 


The SMC appears to the system as a single I/0 channel, to 
which are attached multiple units of various types. These 
units include the Winchester disk, the Remote Port, the 
TESTBUS, the SMC itself, and the MP/ODT. Multiple concurrent 
I/Os are permitted on this channel (under MCPX). Thus, I/0s 
for the OD? are initiated on the appropriate channel and unit 
in the normal manner. 


the MP optionally incorporates a color monitor which is 
utilized by the systems software to enhance console output 
displays. The operator is able to select various color 
combinations according to local preference. 


The utilization of the Maintenance Subsystem to provide the 
ODT function eliminates the need for a Console or Uniline DLP 
wnen only one ODT is required. If more than one ODT is 
included in the configuration, then a Uniline DLP is required 
for each additonal unit. 


Fault tolerant configurations that incorporate two B25s (MPs) 
may use them both to support the OD? function. 


It is planned that the Maintenance Processor will support an 
additonal RS232 interface to an HT1100 or equivalent device in 
the future. 
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The ODT Automatic Display (AD) function is enhanced by the use 
of multiple screen buffers in the MP. The number of pages 
utilized (max. 5), and their format, is determined by the MCP 
based on operator input to an extended AD command. Each page 
type is pre-formatted by the MCP, and contains a page type 
identifier. The MP keeps each page updated in its memory, but 
only displays a page (other than the one currently selected) 
at a specific operator request (hitting a Function Key), or if 
an automatic page rotation scheme has been defined (this is an 
MP function). Thus, the operator has "instant" access to 
various system status reports (MCP Control Messages, I/0 
Status, or whatever) without being locked into a fixed dislay 
Sequence. Other display pages are used for maintenance 
functions. 


When the system is configured with two or more OD@s, it is 
possible to "SAVE" the MP OD? (logically remove it from the 
system), and utilize it exclusively for maintenance functions, 
while the other ODT(s) continue to perform the normal on-line 
function. It is not, however, a requirement that the ODT be 
saved in order to perform on-line maintenance, as the MP may 
perform both ODT and maintenance functions concurrently. 


The "HALT/LOAD" ODT may be designated during each HALT/LOAD by 


the selection of an "ALT ODT" option in the initialization 
menue 
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4.2 REMOTE POR? 


The system Remote Port is an RS232 serial interface to the MP. 
It is accessible to the system in normal mode as a unit on the 
maintenance channel. In off-line mode, it is controlled 
directly by the MP. Security, data encryption/decryption, and 
message protocols, are handled by the MP. 


An optional modem module is available for the maintenance 
susbsystem (AWS configurations only). If this modem is not 
included in the configuration, one must be supplied from 
elsewhere before the remote port can be utilized. 


4.3 MAINTENANCE DISK ACCESS 


The Maintenance (Winchester) Disk is accessible to the system 
as a unit on the maintenance channel. However, the system does 
not have direct access to the disk itself, but has its 
commands interpreted by the MP, which is responsible for 
directory maintenance and all other disk management functions. 
The interface is used for whole file transfer and removal, and 
directory enquiries only, and is primarily intended as an 
on-line update path for maintenance subsystem software. 


4.4 oWAP 


SNAP pictures are written into a reserved area of system 
memory by the SMC. ‘Two SNAP pictures for each processor are 
saved on the Maintenance Disk (the first and last for the most 
recent error event for each processor), and will be passed to 
the MCP in response to the appropriate request. In order to 
reduce total SNAP time, SNAP pictures are buffered in the MP, 
and not written to the disk until the system has been 
restarted. 


The implementation of program level selective SNAP ENABLE is 
TBD. 
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4.5 ERROR LOGGING 


Errors detected by the processor are defined as either "hard" 
or "goft". A hard error is one that can only be caused by an 
actual hardware failure (e.g. a bus parity error). A_ soft 
error is one that (in the absence of a hard error) is assumed 
to be caused by a software error, and therefore does not imply 
any hardware failure (e.g. an invalid address). 


Hard errors are handled by the Maintenance Subsystem directly. 
The error handling process includes stopping the processor 
with the error (possibly more than one processor if the error 
involves shared resources), performing a SNAP and analyzing 
the error indicators, writing a processor RD in system memory, 
and attempting an instruction retry (if this is viable). 


soft errors are handled by system software through a _ soft 
interrupt mechanism. The error handling process may involve a 
SNAP (initiated by a soft request), but this is the extent of 
maintenance subsystem involvement. Soft errors are not 
recoverable via instruction retry. 


Botn types of errors result in entries in the MLOG. Hard 
errors will also be logged and analyzed by the MP. 


Details of the proposed fault handling mechanism may be found 
in the V500 Fault Recovery Guidelines. 


The increased error detection logic in the processor makes it 
possible for the MP to make available to the MCP more specific 
diagnostic information than can be contained in the currently 
defined processor RD. To take advantage of this potential, the 
WP will provide extended RD information available to the MCP 
on request. It is assumed that the MCP will make such a 
request as part of the normal RD handling procedure. 


The MP passes information on non-fatal environmental problems 
(e.8. power brown-out, temperature change) detected by the 
Environment Control Modules to the MCP via the processor SNAP 
mechanism. These SNAPs are handled by the MCP in a manner 
Similar to other non-critical problem reports (e.g. soft 
memory errors). This is the mechanism by which the MCP is 
provided with an "early warning" of problems’ that may 
subsequently require a power down. 
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Ab FATAL MCP ERRORS 


The incidence of "red light" processor halts is expected to be 
extemely low on the V500, due to the improved error handling 
capability of the Omega operating system. Meaningful error 
messaves are displayed on the ODT by the MCP in almost all 
error situations. 


Specific situations in which the MCP cannot communicate an 
error report to the operator are to be defined, and a means 
established whereby the maintenance subsystem can perform this 
function. A design goal is to make a meaningful error report 
available to the operator in all failure situations where 
sufficient hardware to do so remains functional. 


4.7 SOFTWARE DEBUG AIDS 


The complex structure of the Omega software environment make 
it desirable to utilize the intelligence of the maintenance 
subsystem to provide a meaningful analysis of a program or 
system software state for debug. The contents of such an 
analysis, the preferred display format, and any interactive 
commands required, are to be defined. 


4.8 SYSTEM INITIALIZATION 


The maintenance subsystem is responsible for verifying the 
operational state of the system before intialization, and 
performing intialization steps up to the point of loading and 
initiating execution of the system boot program. A meaningful 
error message is provided whenever a problem is encountered, 
including, where applicable, a recommended course of action 
for recovery. Once the system boot program begins execution, 
it (and succeeding levels of system software) assumes 
responsibility for providing error information to the 
operator. 


Loading of any DLP or I/O controller firmware files required 
to begin execution of MCP code is a function of the 
maintenance subsystem. Such files are maintained on the 
maintenance disk, and are updateable by either mini-disk file 
transfer, or on-line file transfer from the system disk. 


Once the system configuration has been defined, system 
initialization can be accomplished by the operator with a 
Single keystroke. (The system configuration need only be 
defined at installation, or whenever the hardware required for 
initialization is reconfigured). 
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49 SYSTEM CRITICAL PATH TST 


The need to provide a means to rapidly isolate a problem which 
prevents the system from being initialized (and hence MCP 
level diagnostics from being utilized), is satisfied by a 
combination of a free-standing pre-boot diagnostic program, 
and the incorporation of a diagnostic capability into the 
bootstrap program itself. 


A pre-boot system critical path test is provided as a part of 
the standard maintenance subsystem software, which may be 
optionally executed every time the system is halt/loaded 
(execution time is less than 60 seconds). This program 
verifies the correct operation of those system components 
required to begin execution of the bootstrap program only. 
Thus it is restricted to checking the maintenance subsystem 
itself, the processor, and a portion of main memory. 


If the system critical path test can be executed successfully, 
sufficient hardware is functional for the bootstrap program to 
execute, and responsibility for providing error messages in 
case of a problem will be assumed by it. 
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5 MAINTENANCE SOFTWARE ARCHITECTURE & DEVELOPMENT? 


The maintenance software is divided into two distinct systems, 
the SMC and the MP. The MP software is designed to run in the 
environment of a relatively sophisticated operating system; 
operator interface and non-time-—critical functions are 
performed in the MP. The SMC provides chain and clock level 
processor interface; time-critical functions such as SNAP and 
event stop are also controlled by the SMC. 
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5.1 MP SOFTWARE ARCHITECTURE 


The Maintenance Processor handles the bulk of the software for 
the Maintenance Subsystem. The screen of the MP serves as both 
system and maintenance ODT; user input to both the maintenance 
and the functional system are through the MP keyboard. 
Operator input for maintenance is analyzed in the MP. A few 
functions, such as interrogation of MP files or certain MP 
software variables, are handled entirely in the MP. Most 
functions will require translation into commands to be sent to 
the SMC. This translation is a large percentage of the MP 
software. 


Functions of the MP include system initialization, diagnostic 
testing, setting up low-level processor clock and chain 
commands, error logging, and remote diagnostic interface. All 
maintenance data files, including control store data, test 
data, screen formats, and register/RAM directories, are 
resident on tne MP's Winchester or floppy disks. 


In most instances, the MP is only performing one function at a 
time, but it must be able to handle concurrency. For example, 
when passive remote software is being run, the MP must be 
handling the ODT function, processing the remote interface, 
and still be able to respond to interrupts if a processor STOP 
or ERROR condition occurs. 


The maintenance processor software is divided into 4 levels: 


LEVEL LANGUAGE DESCRIPTION 


IO DRIVERS Assembly Lowest level - hardware specific 
routines. Generally come with 
the operating system (BTOS). 


OPERATING SYSTEM PL/M Task scheduling, memory & file 
( BIOS ) management, etc. 
GENERAL PROCEDURES PL/W Seanner, display routines, etc. 


Utilize standard BIOS procedures 
where possible. 


APPLICATIONS PL/M State access, system 


initialization, diagnostic test 
drivers, etc. 
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5.1-1 IO DRIVERS 


The IO Drivers are extensions of the operating system which 
provide device-specific interfaces to the hardware. ‘They are 
written in assembly language and are called by higher-level 
routines with a standard set of parameters. These routines 
are largely included with the B25 Operating System (BTOS). 


5.1.2 OPERATING SYSTEM 


The B25 and AWS run BIOS (the B20 operating system) as their 
native operating system. BTOS is a multitasking, 
priority-based interrupt-driven operating system, as is needed 
for the several concurrent MP functions. 


The MP software is being designed to ship on the B25 
initially. For the AWS, low-level modules may have to be 
modified. “he new I/O handlers should come as part of the AWS 
software package. The similarity between B25 and AWS should 
make the conversion relatively straightforward. 
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paras) 


GENERAL PROCSDURES 
MODULE 


File Handler 
(BLOS) 


yeanner 
(BTOS-Executive) 


Sereen 


DLP 


Remote Link 


Host Control 
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SYSTEM DESIGN SPECIPICATION Rev. 


FUNCTIONS 


Create file 

Open/close file 

Read/write sector 

Display directory 

Diskette copy (Mini-Disk) 
Diskette format (Mini-Disk) 
Pile copy 


Accept & parse input commands; 
Accept & parse forms mode input 


Write formatted displays 
Write messages 


Initialize channels 

Handle DLP buffer allocation 
Receive data from host 

send data to host 


Test 
Read 
Write 


Test 
Read 
Write 


Test 
Read 
Write 


Clear interface 
pend data 
Report error status 


A 
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5-1-4 APPLICATIONS 
The applications software in the MP is broken into functional 
modules as follows: 
Maintenance Executive, including: 
Command Analysis 
Initialization of Software variables 
Primitive SMC commands: 
Read/write/display chains 
Clock/clear chains 
Read/write RAMS 
Read/write system memory 
festing: 
Load/initiate control state tests 
Load/initiate module tests 
Path test diagnostic driver 
Test bus driver 
Host system-level commands: 
Set/display system configuration variables 
Clear system memory 


system control & status display 
SI, sc, INIT, HALT, RUN, <SPCFY>, etc 


System initialization - CS load/verify, load MCP 
Set/display conditional stop logic 


Error logging/reporting 
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5.1.4 APPLICATIONS (Continued) 


Other interfaces (non-SMC) 
Remote port interface 


Environmental control 


fee 2 OME OES GD EE om Ge OE KOO we co ow CD a 


Disk boot from system tape 


Floppy disk as host system resource 


File transfer, 
MP video as system ODT 


In addition to programs, 
support these functions. 


These files include: 
Module Directory (MODDRY) 
Ram Directory (RAMDRY) 


Message Directory 


Screen Files - (Menus) 


Control Store Data 


Diagnostic test index 


certain 


system to MP Winchester disk 


data files are necessary to 


- State Access 
- Ram Access 


- Memory Access 
System Control 
Program Load 
Stop Logic 


- Initialization, 
- Stop Logic, 


- System Configuration, ete. 


- for automatic mode of 
running diagnostic tests 


Diagnostic test error message file - Card replace info. 


Test Data 


- Processor diagnostic tests 
Microcoded module tests 
Control state confidence 

tests 
DLP testbus diagnostic tests 
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poe MP SOFTWARE DEVELOPMENT SYSTEM 


Software development will be done on the B20/B25 under BTOS. 
Whe language PL/M has been chosen for several reasons: 


|. It is used for B20 system software development by 
Convergent Technologies and Burroughs. 


2 The language is well structured. 

4 Modules can be separately compiled and linked; in 
addition, Assembly code can be linked directly to PL/M 
modules to provide functionality or speed not obtainable 
through the language itself. 

4. PL/M is very close to Pascal; therefore, existing code 
modules written in Pascal could be converted to PL/M with 
a minimum of effort. 


5. Pi/M is more memory efficient on the B20 than PASCAL. 
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SMC SOFTWARE 


WI 
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The main functions of the SMC software are to accept, 
interpret, and perform commands received from tne MP; and to 
respond to interrupts from the processor, either maintenance 
mode error or stop logic, or normal state DLP-type commands. 
Because of the need to respond to several types of interrupts 
and process them in a timely fashion, it has been determined 
that a simple kernel operating system is needed to facilitate 
SMC software development. The VRTX system, currently being 
used by the Data Comm section in Pasadena, has proven to be an 


efficient, compact, reliable and simple-to-use operating 
system. 
The SMC will be driven by an 80186 microprocessor. The 


software modules are as follows: 


I/O HANDLERS/PDFs 
Maintenance Bus 
IO BUS 
Test bus 


Cluster 
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5.3 SMC SOFTWARE (Continued) 


Self-test 
Initialization 

Decode commands from MP 
DIM Emulator 


Memory Access 
Quick program load 


Processor Fault Handler 
Interrupt decoder 
SNAP 
Retry control 
Processor Chain & Clock Controller 


Processor Ram Loader & Tester 
OPERATING SYSTEM (VRTX) 


5.4 SMC SOFTWARE DEVELOPMENT SYSTEM 


Software for the SMC will be developed on INTEL MDS's. some 
time-critical functions will be written in Assembler. Other 
oo of the code can be written in PL/M (supported by 
Intel). 


The use of VRTX requires a PL/M interface library to be 


supplied by Hunter & Ready. such a library is already 
available within the plant. 
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